Lab 5 - Software Hardening

This lab is intended to give you a taste of hardening software in Linux. It is neither an exhaustive list of recommendations nor even a list of things that apply to all systems. It is simply meant to give you practice in changing software settings and testing those changes.

Grading

This lab counts for marks. Submit your results and screenshots as per instructions posted on Blackboard. For the screenshots, you only need to include enough in your screenshots to show your bash prompt, the command you ran, and the output that demonstrates what you did or that the command works. For the roundcube web page screenshot, you only need to show the login succeeded as there is no email in the account.

Over-riding default file permissions in package executables

  1. Following the example in the slides, modify your sudo executable to only be accessible for execution by the file owner and the file’s group

    sudo dpkg-statoverride --update --add root sudo 4550 /usr/bin/sudo
    sudo dpkg-statoverride --update --add root sudo 4550 /usr/bin/sudo
  2. Before exiting your current bash session, start a second terminal window and ensure you can still use sudo

  3. Does debsums complain about your modified sudo program? How about dpkg with the verify option? - submission question!

    debsums sudo | grep /usr/bin/sudo
    sudo dpkg --verify sudo 
    debsums sudo | grep /usr/bin/sudo
    sudo dpkg --verify sudo 
  4. Use the list option of dpkg-statoverride to view all programs with overrides on your system - screenshot!

    dpkg-statoverride --list 
    dpkg-statoverride --list 

Apparmor

  1. Run aa-status to see what the current state of apparmor is on your VM

    sudo aa-status 
    sudo aa-status 
    • Tip: You may need to install apparmor-utils to get access to these utilities
  2. Try the aa-unconfined utility to see what processes are running that have tcp or udp ports and their apparmor status

    sudo aa-unconfined 
    sudo aa-unconfined 
  3. Review the list of profiles contained in the Ubuntu 24.04 apparmor-profiles package list of files package. Are there profiles in that package for the /etc/apparmor.d directory which would confine software that is running unconfined on your system now? - submission question!

    • Tip: Compare the unconfined list to the list of available profiles in the online repository!
  4. Try using the –paranoid option for aa-unconfined to see if there are processes which could be confined by the apparmor-profiles package which aa-unconfined did not show without that option

    sudo aa-unconfined --paranoid 
    sudo aa-unconfined --paranoid 
  5. Review the content of the apprmor profile for the tcpdump network snooping program

    # Needed to look at "/etc/apparmor.d/usr.bin.tcpdump" line by line and explain what each line or each section of the code does.
    cat /etc/apparmor.d/usr.bin.tcpdump 
    # Needed to look at "/etc/apparmor.d/usr.bin.tcpdump" line by line and explain what each line or each section of the code does.
    cat /etc/apparmor.d/usr.bin.tcpdump 
  6. Using the apparmor man page, determine the kinds of limitations that are placed on that program by the profile. Explain the lines and be specific about the capabilities and permissions given. - submission question!

sudo Configuration

Digital Ocena’s tips page for sudo privileges is a helpful resource when looking for how to edit sudo permissions.

  1. Modify your sudo executable to be accessible for execution by any user, so that we can use the sudoers file to control access instead

    • Tip: You may need to remove the prior override before applying new override.
    sudo dpkg-statoverride --update --add root sudo 4555 /usr/bin/sudo 
    sudo dpkg-statoverride --update --add root sudo 4555 /usr/bin/sudo 
  2. Modify your /etc/sudoers file to limit the dennis account so that they can only use root sudo to edit their own domain zone file (/etc/bind/db.server45678.mytld) and reload named using the rndc reload command. Provide a screenshot of your modified configurations - screenshot!

    visudo 
    visudo 
  3. In a second ssh session, login as user dennis (password is dennis) and verify that user dennis can use sudo to edit their zone file and to run rndc reload but cannot use sudo to run another command, such as bash (User should NOT be able to do sudo to run any other commands!)

    dennis$ sudo vi /etc/bind/db.server45678.mytld
    dennis$ sudo rndc reload
    dennis$ sudo bash 
    dennis$ sudo vi /etc/bind/db.server45678.mytld
    dennis$ sudo rndc reload
    dennis$ sudo bash 
  4. List out the sudo configuration for user dennis - screenshot!

    dennis$ sudo -l 
    dennis$ sudo -l 
    • Note: Make sure your permissions are correct, for example, dennis is only capable of modifying the specified file and nothing else.

BIND improvements

  1. Following the information given in "Security Configuration" of the Bind9 Administrator’s Reference Manual (ARM), secure your bind service by:

    • adding the bogusnets acl as shown in the ARM (in /etc/bind/named.conf.options)
    • setting up the allow-query, allow-recursion, and blackhole directives as shown in the ARM (in /etc/bind/named.conf.options)
    • allowing queries from anywhere for the zones being served by the server (in named.conf.local)
  2. Verify your DNS service reloads the new configuration properly, and that your domain lookup still works:

    sudo rndc reload 
    nslookup www.server45678.mytld
    sudo rndc reload 
    nslookup www.server45678.mytld
  3. Provide Screenshots of the following: - screenshots
    a. Screenshot/contents of modified /etc/bind/named.conf.local file
    b. Screenshot/contents of modified /etc/bind/named.conf.options file
    c. Screenshot of bind9 service status: sudo service bind9 status
    d. In a terminal or powershell window on your host laptop/computer, run nslookup www.server45678.mytld ip-of-your-vm to verify your domain service is still available to non-local clients

MySQL basic hygiene

  1. Run the mysql_secure_installation script to clean up after the install - screenshot!

    • do not enable password validation
    • set the root password to root
    • remove anonymous users
    • disallow remote root login
    • remove the test database
    • reload the privilege tables
      NOTE: Depending on your VM configuration you may see an error when trying to execute mysql_secure_installation about the authentication method as follows:
    ali@pc12345678:~$ sudo mysql_secure_installation
    Failed! Error: SET PASSWORD has no significance for user 'root'@'localhost' as the authentication method used doesn't store authentication data in the MySQL server
    
    # This is probably because your MySQL server is not using "mysql_native_password"
    # You can login to MySQL Server and change the root account authentication using the following method:
    ali@pc12345678:~$ sudo mysql
    [sudo] password for ali:
    ### < output redacted for clarity >
    mysql> alter user 'root'@'localhost' identified with mysql_native_password by 'root';
    Query OK, 0 rows affected (0.02 sec)
    mysql> exit
    Bye
    ali@pc12345678:~$ sudo mysql_secure_installation
    Failed! Error: SET PASSWORD has no significance for user 'root'@'localhost' as the authentication method used doesn't store authentication data in the MySQL server
    
    # This is probably because your MySQL server is not using "mysql_native_password"
    # You can login to MySQL Server and change the root account authentication using the following method:
    ali@pc12345678:~$ sudo mysql
    [sudo] password for ali:
    ### < output redacted for clarity >
    mysql> alter user 'root'@'localhost' identified with mysql_native_password by 'root';
    Query OK, 0 rows affected (0.02 sec)
    mysql> exit
    Bye
  2. Access the web page at http://your-vm-ip/roundcube and put in the student account name and password, server localhost to verify that the mysql database service is still running properly - screenshot!

Email client access

Emails clients may try to transmit usernames and passwords in clear text. Depending on the client software, there is no guarantee that all clients will check supported protocols and will use encryption by default when attempting to connect to the server. An external email client should not be able to attempt a connection using unencrypted protocols if it can be helped. Additionally, we do have an internal email client, Roundcube, that uses IMAP locally.

  1. Given the information above, identify what you would need to change in Dovecot configurations to disable POP3 and disallow IMAP from being accessed by remote hosts, and enforce POP3S and IMAPS services. - submission question!
  2. Verify that the changes have taken effect using sudo ss -tlpn | grep dovecot - screenshot
  3. Make sure that you can still log into Roundcube at http://your-vm-ip/roundcube and view a user mailbox. - screenshot
  4. Taking a layered security approach what firewall changes would you make to the existing labVM system to limit email clients to only POP3S and IMAPS? Provide commands or output snippets from your firewall configuration - submission question!

Known vulnerabilities

  1. Is your LabVM's RoundCube installation vulnerable to CVE-2025-49113? - submission question!
  2. Is your VM susceptible to the heartbleed vulnerability? Show what you did to check. - submission question!

Unexpected programs on your system

  1. A sample script is provided below, but you may need to modify or improve this.
    • The given script looks for any executables that are not installed using the dpkg/apt package manager. This can be used to audit a system and to find any rouge and unexpected or potentially malicious programs. Additionally, this helps to identify programs or packages that may not be maintained, updated, or easily audited using dpkg/apt.
    • The script is imperfect and outputs a lot of lines.
    • What are the sources of all these unknown executable files? List all the sources that you find with examples from the output of the script. - submission question!
      • Tip: You are being asked to find the potential sources that these executables are coming from, since dpkg/apt did not install them!
#!/bin/bash

# simple script to identify files that are executable (programs) which did not come form installed system packages
# could be improved in a number of ways

IFS=$'\xa'
find / -type f -executable >/tmp/filelist.$$
for file in $(cat /tmp/filelist.$$); do
    dpkg -S "$file" >/dev/null 2>/dev/null || echo "$file"
done

rm /tmp/filelist.$$
#!/bin/bash

# simple script to identify files that are executable (programs) which did not come form installed system packages
# could be improved in a number of ways

IFS=$'\xa'
find / -type f -executable >/tmp/filelist.$$
for file in $(cat /tmp/filelist.$$); do
    dpkg -S "$file" >/dev/null 2>/dev/null || echo "$file"
done

rm /tmp/filelist.$$
  1. Either modify the script to improve the output to remove some of the known sources or analyze the output to see if there are any unexpected and potentially suspicious programs on your lab VM. - submission question!